🐈 當走在路上，發現了橘貓，橘色、貓、胖，就這樣綁定了目光，牠喜歡吃東西，可能討厭下雨天等，根據這些資訊，可以判斷出牠的下一步往哪走......這些日常概念，也可見於K8s，實現在object之間的綁定，或者是pod分配到節點的規則等

關於我以及如何找到我- Label and selector

標籤 Label
為key/value格式，用來標定object，加上這些屬性能幫助我們識別其用途、做分類。標籤不具有唯一性，在查詢時一把抓好幾個物件，像是可以標定好幾個Pod是前端(tier: frontend)且屬於特定業務功能(project: data-migration)，或是讓object能適當配對。像是搜尋橘色及貓(2個labels)，可以找到多隻橘貓(label非唯一性識別)，符合條件即成功收編(matchLabels)，也可以只搜橘色，那可能就會查到，橘貓、橘子、荷蘭...

label的名稱分為2部分：

1. 前綴名稱(prefix)，和名稱與"/"區隔，若設定則需為DNS subdomain，以"."分隔，需少於 253字；若不設定，則假定為用戶私有，kubernetes.io/ 及 k8s.io/ 保留給核心元件使用
2. 名稱: 需少於63，開頭與結尾需為[a-z0-9A-Z]，中間可以有符號，連接號"-"、底線 "_"和點 "."

• 舉例: climate:subtropical、tai886wan.hello/climate:tropical

選取器 Selector
用來操作要選取的label，API目前支援兩種方式

1. 基於相等(Equality-based): 比對是否相符，操作子(operator)有=、==、!=，以ReplicaSet為例，在管理pod數量時，即透過比對label-selector決定要管理的pod有哪些

apiVersion: apps/v1
kind: ReplicaSet
metadata:
  name: frontend
  labels:
    app: ithome
    tier: frontend-replicaset
spec:
  selector: # 指定此replicaset綁定符合特定label的pod
    matchLabels:
      tier: frontend
  template:
    metadata:
      labels: # pod標籤設定
        tier: frontend
        environment: dev
    spec:
      containers:
      - name: label-demo
        image: nginx

2. 基於集合(Set-based): 是否屬於特定清單內有的值，操作子有in、notin 及 exists，以Pod為例，指定分配的node其label需有特定key，value需在清單[tropical, subtropical]，利用label，讓pod適得其所(分配到適合的node)，像是有些pod需求高cpu、有些需求高memory

apiVersion: v1
kind: Pod
metadata:
  name: pineapple-pod # 鳳梨
spec:
  affinity:
    nodeAffinity: # 需求的node環境
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms:
        - matchExpressions: # 在比較熱的氣候
          - key: climate
            operator: In
            values:
            - tropical
            - subtropical
  containers:
  - name: with-node-affinity
    image: registry.k8s.io/pause:2.0

Label && selector操作指令

# 查詢pod, 條件指定(selector)特定標籤
kubectl get pods --selector <key1>=<value1>, <key2>=<value2>......
# 將node(或其它object)打上標籤
kubectl label node <名稱> <key>=<value>
# 覆寫標籤
kubectl label --overwrite pods <名稱> <key>=<value>
# 移除標籤，使用減號
kubectl label pods <名稱> <key>-
# 建立object時, 指定標籤, deployment為例
kubectl create deployment --image=nginx nginx-deploy --namespace=dev-ns --labels="tier=frontend"

我覺得不行 - Taints && Tolerations

label-selector為明確選取的設計(正向)，另外也有排斥的設計(負向)，在分配Pod到節點時會使用到，節點只會分配到具有對應耐受性的Pod，不過反過來說pod不一定要分配到此node，可以設定有多個taints/tolerations，官方舉例有：Node規劃給特定用戶使用，或是Node配置特定資源，因此只開放給需用到這些資源的Pod使用等

• Tolerations: 耐受，設定在pod，預設情況，Pod不會有任何toleration
• Taints: 汙點，設定在node，針對pod的效果(taint-effect)有下列3種
  1. NoSchedule：防止新的pod被調度到標記了該Taint的node上，不影響既有在node上面的pod
  2. NoExecute：如果node上已經存在pod，但該Pod不符合Taint的規則，則node上的現有pod會被驅逐(evict)
  3. PreferNoSchedule：盡量不要把pod分配到該節點，委婉版的NoSchedule

節點管理器(node-controller)會根據情況增加/移除taints，避免pod被分配到不健康的node，自動加上的taints像是：

• node.kubernetes.io/not-ready: 效果為NoExecute，避免node崩壞
• node.kubernetes.io/unreachable: 效果為NoExecute，避免node崩壞
• node.kubernetes.io/disk-pressure: 效果為NoSchedule，現有pod可執行，但要避免持續分配pod，以免node超出負荷

Taints && Tolerations操作指令

# 加上taints，指定效果，value不是必填
kubectl taint nodes <名稱> <key>=<value>:<effect>
# remove taint，使用減號，若key有前綴也需寫出
kubectl taint nodes <名稱> <prefix>/<key>:<effect>-

今天，想要去哪裡- Node Affinity

分配pod的時候，有個設定為親和性「affinity」，可以不同程度的選擇要去哪個node，同樣運用到label-selector來比對目的地

apiVersion: v1
kind: Pod
metadata:
  name: nginx
spec:
  affinity: # 設定親和性
    nodeAffinity: # 設定類型
      requiredDuringSchedulingIgnoredDuringExecution:
        nodeSelectorTerms: # 設定條件
        - matchExpressions:
          - key: disktype
            operator: In
            values:
            - ssd            
  containers:
  - name: nginx
    image: nginx
    imagePullPolicy: IfNotPresent